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Abstract. Today's astronomical projects need computa- 
tional systems capable to store and analyze large amounts 
of scientific data, to effectively share data with other re- 
search Institutes and to easily implement information ser- 
vices to present data for different purposes (scientific, 
maintenance, outreach, etc.). Due to the wide scenario of 
astronomical projects there isn't yet a standardized ap- 
proach to implement the software needed to support all 
the requirements of a project. The new approach we pro- 
pose here is the use of a unified model where all data are 
stored into the same data base becoming available in dif- 
ferent forms, to different users with different privileges. 



1. Introduction 

Information services can be separated in two classes: those 
in which the information produced are addressed to hu- 
mans, and those in which they arc meant for the use by 
other software applications. In the former case there is 
a quite standardized way to develop such an information 
service, essentially based upon a web server, a database 
server, a scripting language and HTML pages. In the latter 
case instead there is no such standardization, and here's 
why MCS (My Customizable Server) was implemented. 

MCS is a set of software tools aimed at easily imple- 
ment information services, that is an application that pro- 
vides a service over the network. At the core of a MCS- 
based system there is a TCP server which listen for user 
connections, and once a user is connected it will send all 
the requested information. However the transmitted data 
aren't in free format (like in a web page), but are packed 
in a well defined fashion (using the MCS protocol) so that 
on the other side a software can understand what is be- 
ing sent. The MCS high level classes will hide all code 
implementations related to multi-threading, networking, 
database access, etc., and require no low- level knowledge 
of these issues by the users. MCS can also be customized 
through the derivation of some classes. So MCS and its 
protocol are for software applications what a web server 
and HTTP are for the WWW: a simple way to access 



data. In this comparison customizing the MCS server is 
like writing a web page. 

MCS is the evolution of a software named SDAMS 
(SPOrt Data Archiving and Management System) 
INicastro fc C alderone 20021 that was implemented to sup- 
port the SPOrt experiment ( |Cortiglioni et al. 2004| , an 
Italian Space Agency (ASI) funded project which has 
been "frozen" because of the problems with the Columbus 
module on the International Space Station. At that time 
the approach used to build SDAMS seemed to be easily 
portable to other experiments so its features and usability 
has been generalized until it became the actual MCS. In 
fact it is now used to manage the data collected by the 
optical camera ROSS (jTosti et al. 2004P mounted on the 
robotic telescope REM (|Covino et al. 2004P at La Silla, 
Chile (see Nicastro & Calderone, this volume). 

MCS has been developed on the GNU/Linux platform 
and is released under the GPL license. It can be freely 
downloaded from the site ross.iasfbo.inaf.it/mcs/. This site 
contains all news, updates, documentation and download- 
able software packages. The documentation is present as 
a user manual (in pdf format) which focuses on the main 
aspects of an MCS-based application, describes the server 
environment, commands, and the interfaces for various 
languages, and as a technical reference documentation for 
all MCS's classes (in html format, automatically gener- 
ated using Doxygen). The site is still under development, 
so check for updates. 

2. The MCS architecture 

The MCS core is basically a set of high level C++ classes 
aimed at providing all the functionalities of an application 
server, that is an application that will listen for user's 
request coming from the network, eventually will access a 
database and/or execute an external program, then it will 
send the answer to the user using the MCS protocol. The 
main features of application servers built with MCS are: 

— easy to configure; 

— authentication and grant support; 

— secure connections (through SSL); 

— database access (MySQL); 
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Table 1. MCS and Unix "shell" comparison. 



227 




MCS server 



Client 

C, C++, Fortran. IDL. PHP 



Shell script 



Fig. 1. Main components of an MCS based system. 

— base commands set, support to create new customized 
commands; 

— accessibility (as clients) from other languages such as 
C, Fortran, IDL, PHP, etc.; 

— logging facility, etc. 

All these features are already available, without perform- 
ing any customization. So to implement a simple service 
with the above features you'll only need to install MCS 
and configure it through a simple configuration file. The 
only code needed is as follows: 

//Mandatory includes for every MCS-based appl. 
#include <mcs.hh> 
using namespace mcs; 
//Main program 

int main(int argc, char *argv[]) { 
//Start the server... 
Env* env = mcsStart ("simplest") ; 
//...and wait for its end 
mcsWait (env) ; 

> 

For more complex services you can customize the server 
behavior in several ways: 

— adding external programs, either real external applica- 
tions or batch lists of MCS commands; 

— adding SQL programs, to be executed on the database 
server; 

— adding customized commands, deriving the 
UserThread class; 

— modifying the behavior of the server side thread, de- 
riving the LocalThread class; 

In a typical application you should implement a 
database with all the tables needed to store all the rel- 
evant data related to the project, and eventually prepare 
the required external programs. Figure [T] shows the typi- 
cal architecture of an MCS-based system: 
Database server: the database server is used to handle 
clients authentication, to store all application specific data 
and anything else necessary to the application itself. This 
server isn't accessible directly from the clients, but it is 
visible only to the application server. At the moment the 
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only supported database server is MySQlQ. In the future 
other servers may become accessible through MCS. 
Application server: the application server is the core of 
the information system. It implements the client/server 
model: a client opens a TCP socket towards the host run- 
ning MCS and sends a request, then the server "computes" 
an answer, eventually querying the database and/or exe- 
cuting some external programs, and sends it back to the 
client. The behavior of the MCS server can be customized 
deriving some classes. 

External programs: external programs are software ap- 
plications written in any language, which interact with 
the application server via command line and the standard 
output. Support to these programs was added to easily 
integrate already existing applications within MCS. 
Clients: clients are programs which access the MCS ser- 
vice over the network. Such programs can be written in 
any language and run on any platform, provided that they 
implement the MCS protocol. Interfaces that implement 
the MCS protocol are provided by the MCS library for 
the following languages on the Linux platform: C++, C, 
Fortran, IDL, PHP. Support for other languages (such as 
Java, Python and Perl) and the Windows platform will be 
available soon. 

Note that such a system would not be a closed model, 
in the sense that existing databases and/or software tools 
may be integrated into the MCS-based systems. That's be- 
cause MCS doesn't make any assumption about type and 
quantity of data you need to deal with. It uses a relational 
database system to store many of its data. Databases have 
become today the most useful, scalable and flexible way 
to store and give access to any sort of data. 

From a user's point of view MCS is very similar to the 
usage of a classic Unix shell, that is a command line inter- 
face with a prompt on which users can execute commands 
in their own environment and wait for the output before a 
new command is issued. It is therefore possible to make a 
comparison between the "components" of a shell, and the 
ones from an MCS connection (see Tab. [J). 

The output of a command won't be ASCII text like 
in a shell. Data will be instead formatted using the MCS 
protocol and can be sent and received in binary form in 
both directions. Figure [5] shows the typical sequence of 
events during an MCS session. 
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Fig. 2. Flow diagram of a typical MCS session. 



MCS classes can also be used outside an application 
server, for example it is possible to write a program in 
C++ which uses the DBConn and Query classes to 
access a database, or one of the VOT_Parser_Tree or 
VOT_Parser_Stream classes to read VOTable file. The 
same program can also be written in one of the languages 
for which we have an interface (at the moment C, Fortran, 
IDL, PHP; other will be developed in the near future). 

2.1. Deriving MCS classes 

Deriving a C++ class means creating a new class that has 
all the behaviour characteristics of an existing one (the 
parent class), plus some more specific behaviour added. 
In the MCS case the server behaviour can be customized 
through the derivation of the User/Thread class (more 
specifically only the "virtual" methods should be derived, 
as described in the documentation) . This way it is possible 
to create custom commands available as if they were "base 
commands" (see Tab. [IJ. Another class that can be de- 
rived for customization is Local Thread. It runs in a server 
side thread, independently from other client threads. This 



class can be used to implement some server side tasks like 
data quick look or reduction, database maintenance, etc. 

3. A real life example 

In a typical scientific experiment we have an instrument 
producing data, a main storage system, a set of software 
tools to perform analysis, and people with different needs 
who wish to access the data. In this section we'll analyze 
the components of an informative system based on MCS, 
applied to such an experiment. A common use of MCS in 
such a real life project would be as follows: an MCS server 
is running on the computer attached to the scientific in- 
strument and collects data on local disks. Over these data 
the MCS server will eventually perform some automatic 
analysis for data quick-look, then will store the results and 
the raw data in the database. The quick-look tool can be 
implemented in CH — h, or it can be a previously written 
software; in the latter case you only need to implement a 
simple interface between this tool and MCS. A technician 
can then connect via a simple telnet terminal to the MCS 
server and check if everything goes fine. This can be done 
using mnemonic command codes, very similar to the com- 
mands issued in an ordinary Unix shell. These command 
codes can of course be customized. A researcher can use 
the "Client" class to develop a client tool to connect to 
the MCS server and perform a remote control of the in- 
strument or retrieve scientific data in a variety of formats 
(typically formats are raw, ASCII, FITS or VOTable). As 
already mentioned, if the researcher doesn't want to use 
C++ to implement the client tool, he can use one of the 
available interfaces to MCS from other programming lan- 
guages such as C, IDL, Fortran or PHP. One of the main 
feature of these interfaces is that the function names are 
the same in all languages. Finally there can be a web server 
that connects to MCS through a PHP interface and pro- 
vides bookkeeping and outreach information as web pages 
to external users. Each afore-mcntioncd user can of course 
have different privileges, and so being able to view and re- 
trieve different kinds of data. 

4. MCS and the Virtual Observatory 

MCS doesn't pretend to be an all-comprehensive, multi- 
wavelength repository for astronomical data like the Vir- 
tual Observatory is, nor a general purpose data analysis 
software. In this sense MCS is (of course) not a Virtual 
Observatory competitor. Instead it was implemented to 
easily setup real time information services, while reusing 
much of the already existing software tools and database 
tables. However in the near future MCS will implement 
the PLASTIC! interface to connect and use the Virtual 
Observatory facilities. 

MCS can also be seen as a starting point to implement 
or simply make practice with a distributed computing en- 
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vironment like in the "GRID" based projects. A network 
of computers, each running an MCS server, can connect to 
all the others as client to perform computation or database 
queries. Of course, also in this case MCS and "GRID" are 
not competitors because they are supposed to be used for 
different purposes: in fact implementing a service and set- 
ting up an MCS server is much more simple than setting 
up a node or putting a service on the "GRID". On the 
other hand the "GRID" projects offer many more features 
than MCS does. 

5. The MCS companion tools 

We have developed a number of software tools that can 
be used with MCS to improve its functionalities (of course 
these software can also be used as standalone): 

— MyRO (My Record Oriented privilege system): this 
software provides a natural extension to the MySQL 
privilege system, offering the possibility to specify priv- 
ileges on a record level. It supports users and groups 
like those of a Unix system, giving the possibility to set 
a read and/or write permission to each record. Needs 
MySQL version 5. 

DBEngine for FITS and VOTable: a DBEngine 
is a software library linked into the database server 
(MySQL in this case) which let users read and write 
tabic in a format different from the MySQL propri- 
etary Our software let you read and write FITS and 
VOTable files as if they were database tables (this soft- 
ware is still under development). 

Database interface to HEALPix and HTM: 

this software provides some of the functions of the 
HEALPix and HTM library as MySQL functions, to be 
used directly in SQL queries. Functions allowing (fast) 
circular and rectangular selections of entries in HTM 
indexed database tables will also be available soon. 

6. The future 

MCS is in continuous development. It will soon implement 
interfaces for other languages such as Python, Perl, Java, 
Tcl/Tk. Another feature that will be implemented soon 
is the integration with MyRO to handle a more complex 
privilege system. 

User contributed libraries for the various supported 
languages are being built. This will allow an even eas- 
ier access to the MCS functionalities to non expert pro- 
grammers. Moreover, commonly used, independently de- 
veloped external packages will also be included and made 
accessible trough MCS. They include the afore mentioned 
HEALPix and HTM libraries for sky pixelization scheme, 
the Naval Observatory Vector Astrometry Subroutines 
(NOVAS - aa.usno.navy.mil/software/novas) used for as- 
trometric calculations and transformations, the World Co- 
ordinate System (WCS - fits.gsfc.nasa.gov/fits_wcs.html) 
library and tools. 



7. MCS is already used by... 

MCS is already used for managing the data produced by 
the ROSS camera. The SPOrt experiment, whenever it 
will be resumed, will have the data fully managed by an 
MCS based system. The Astrometry group of the Turin 
Astronomical Observatory is making use of the MCS client 
library through the IDL interface to cross match HTM 
indexed catalogues. Other astronomical experiments from 
the gamma-rays to the radio band have shown interest to 
use MCS for their data management. One of them is the 
Italian gamma-rays satellite AGILE. 

8. Conclusions 

Several astronomical projects are still supported by soft- 
ware developed under an old conception: handling all data 
files with "ad- hoc" developed scripts, running stand alone 
applications which can read only proprietary ASCII or 
binary files, relying on users responsibility to follow the 
format and naming specifications for files, absence of any 
mechanism to automatically update a web site, etc. How- 
ever today information technology offers a lot of new tools 
which can give several benefits to astronomers: database 
systems to efficiently store and retrieve huge quantities of 
data, libraries to easily distribute data across the network, 
widely used standard formats for information interchange 
using freely available libraries, new high level languages to 
quickly implement sophisticated data handling and pro- 
cessing, and so on. All of these tools are being effectively 
used by the Virtual Observatory and GRID projects. They 
will become the standard "de-facto" in the near future, 
so software developers involved in astronomical projects 
should start to get used to these new technologies. MCS 
aims at being the simplest and fastest tool to let develop- 
ers build new software to support scientific projects using 
these new technologies. 

Acknowledgements. The SPOrt experiment was supported by 
ASI. The REM Observatory is supported by INAF. 

References 

Cortiglioni S., Bernardi B., Carretti E., et al., 2004, New As- 
tron. 9, 297 

Covino S., Stefanon M., Sciuto G., et al., 2004, SPIE Sym- 
posium, Proc 5492, 1613, G. Hasinger & M. J. L. Turner 
eds. 

Nicastro L., Calderone G., 2002, AIP Conf. Proc. 609, 279, S. 
Cecchini, S. Cortiglioni, R. Sault & C. Sbarra eds. 

Tosti G., Bagaglia M., Campeggi O, et al., 2004, SPIE Sym- 
posium, Proc 5492, 689, G. Hasinger & M. J. L. Turner 
eds. 



